Vulnerability Note VU#800113

The Domain Name System (DNS) is responsible for translating host names to IP addresses (and vice versa) and is critical for the normal operation of internet-connected systems. DNS cache poisoning (sometimes referred to as cache pollution) is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching nameserver. DNS cache poisoning is not a new concept; in fact, there are published articles that describe a number of inherent deficiencies in the DNS protocol and defects in common DNS implementations that facilitate DNS cache poisoning. The following are examples of these deficiencies and defects:

• Insufficient transaction ID space
  The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID. Some flawed implementations may use a smaller number of bits for this transaction ID, meaning that fewer attempts will be needed. Furthermore, there are known errors with the randomness of transaction IDs that are generated by a number of implementations. Amit Klein researched several affected implementations in 2007. These vulnerabilities are described in the following vulnerability notes:
  
  
  • VU#484649 - Microsoft Windows DNS Server vulnerable to cache poisoning
  • VU#252735 - ISC BIND generates cryptographically weak DNS query IDs
  • VU#927905 - BIND version 8 generates cryptographically weak DNS query identifiers

• Multiple outstanding requests
  Some implementations of DNS services contain a vulnerability in which multiple identical queries for the same resource record (RR) will generate multiple outstanding queries for that RR. This condition leads to the feasibility of a "birthday attack," which significantly raises an attacker's chance of success. This problem was previously described in VU#457875. A number of vendors and implementations have already added mitigations to address this issue.

• Fixed source port for generating queries
  Some current implementations allocate an arbitrary port at startup (sometimes selected at random) and reuse this source port for all outgoing queries. In some implementations, the source port for outgoing queries is fixed at the traditional assigned DNS server port number, 53/udp.

An attacker with the ability to conduct a successful cache poisoning attack can cause a nameserver's clients to contact the incorrect, and possibly malicious, hosts for particular services. Consequently, web traffic, email, and other important network data can be redirected to systems under the attacker's control.

Apply a patch from the vendor
A number of vendors have released patches to implement source port randomization in the nameserver. This change significantly reduces the practicality of cache poisoning attacks. Please see the Systems Affected portion of this document for additional details for specific vendors. Additional information about Japanese vendors can be found in JPCERT/CC JVNVU#800113.

Stub resolvers are also vulnerable to these attacks, so system administrators should patch stub resolvers that issue queries in response to attacker behavior and that may receive packets from an attacker. Administrators should watch for patches to client operating systems that implement port randomization in the stub resolver.
Note: Routers, firewalls, proxies, and other gateway devices that perform Network Address Translation (NAT)--more specifically Port Address Translation (PAT)--often rewrite source ports in order to track connection state. When modifying source ports, PAT devices can reduce source port randomness implemented by nameservers and stub resolvers (conversely, a PAT device can also increase randomness). A PAT device can reduce or eliminate improvements gained by patching DNS software to implement source port randomization.

Restrict access

Administrators, particularly those who are unable to apply a patch, can limit exposure to this vulnerability by restricting sources that can ask for recursion. Note that restricting access will still allow attackers with access to authorized hosts to exploit this vulnerability. The document "Securing an Internet Name Server" contains instructions for restricting recursion in ISC BIND.

Filter traffic at network perimeters
Because the ability to spoof IP addresses is necessary to conduct these attacks, administrators should filter spoofed addresses at the network perimeter. IETF Request for Comments (RFC) documents RFC 2827, RFC 3704, and RFC 3013 describe best current practices (BCPs) for implementing this defense. It is important to understand your network's configuration and service requirements before deciding what changes are appropriate.

Run a local DNS cache
In lieu of strong port randomization characteristics in a stub resolver, administrators can protect their systems by using local caching full-service resolvers both on the client systems and on servers that are topologically close (on the network) to the client systems. These resolvers should be used in conjunction with the network segmentation and filtering strategies mentioned above.

Disable recursion
Disable recursion on any nameserver responding to DNS requests made by untrusted systems. "Securing an Internet Name Server" contains instructions for disabling recursion in various versions of ISC's BIND.

The U.S. National Institute of Standards and Technology (NIST) Special Publication 800-81 "Secure Domain Name System (DNS) Deployment Guide" contains detailed and thorough information about the secure deployment of DNS servers, including the recommendations above. Administrators are strongly encouraged to review this document and consider implementing the recommendations it describes.

Implement source port randomization
Vendors that implement DNS software are encouraged to review IETF Internet Draft "Measures for making DNS more resilient against forged answers" for additional information about implementing mitigations in their products. This document is a work in progress and may change prior to its publication as an RFC, if it is approved. System implementers may also wish to review IETF Internet Draft "Port Randomization" for a more generalized approach to how port randomization can mitigate some other types of spoofing attacks.

As noted above, routers, firewalls, and other gateway devices that perform NAT/PAT may modify source ports in ways that reduce the effectiveness of source port randomization.